The Common Object Request Broker Architecture (CORBA) is an open architecture and infrastructure that computer applications employ to synchronously communicate with each other over computer networks. The CORBA specification is published by Object Management Group (OMG) and the specification is accessible via the OMG website: www.omg.org. Briefly, one CORBA-compliant application running on one computer on a network can interoperate with another CORBA-compliant application running on another computer on the network, regardless of their respective hardware platforms, operating systems, and programming language. CORBA is a type of “middleware” that can be used in a client-server architecture to enable client applications to perform remote procedure calls for functions or services provided by server applications. In this context, an application providing services or functions is known as a “server” and applications using those services or functions are known as “clients.” There can be many clients, but typically there is only one active server.
The Data Distribution Service (DDS) is a data communication methodology that is used in connection with distributed applications. The DDS specification, which is also published by OMG, standardizes the software application programming interface (API) by which a distributed application can asynchronously exchange information based on a publish-subscribe model. In this context, applications producing data are known as “publishers” and applications consuming data are known as “subscribers.” DDS can be utilized as the communication interface for a software application. The DDS specification is available from the OMG website.
A process known as CORBA object discovery (hereinafter “discovery”) is performed to enable CORBA client-server communications in a computer network. Discovery is a cooperative process that is performed by the CORBA server and respective client. Each entity must perform specific tasks to complete the discovery process before CORBA client-server communications can take place. FIG. 1 is a diagram that illustrates CORBA discovery between a server 102 and a client 104 in a network. In accordance with the CORBA specification, server 102 creates a servant object 106 that includes a service interface. The service interface is defined using the OMG Interface Description Language (IDL), and the service interface is stored in an IDL file. The IDL file is processed by a CORBA IDL compiler, which generates code to be implemented by server 102 (e.g., a skeleton class for the server interface), and code to be implemented by client 104 (e.g., a proxy class containing stubs to the service interface). Next, server 102 advertises the servant 106 to clients on the network using one or more conventional techniques (discussed below). To support CORBA communication, client 104 needs to obtain a reference to servant 106, which client 104 uses to create a servant proxy 108 (hereinafter “proxy”). The servant proxy 108 is a surrogate incarnation of the service interface. After the proxy 108 is created a client-server connection 110 exists and communication is enabled for that particular client 104. Thereafter, client 104 can invoke the remote operations declared in the service interface via proxy 108 as local calls.
CORBA discovery is usually performed at startup (especially in embedded-system environments). Several known methods can be used to perform discovery, however, each of these methods has its own set of deficiencies. These methods can be complicated, they require other CORBA-defined services, they consume system resources (e.g., system memory), and/or are expensive to implement, test, and maintain.
One existing CORBA discovery methodology requires the server to write the Interoperable Object Reference (IOR) for the servant to a file or other non-volatile memory. In this regard, an IOR is a text string containing endpoint information, i.e., “how-to” instructions for making a connection to the servant object. An IOR is created by “stringifying” the servant object reference, i.e., invoking the CORBA-defined operation named object_to_string. An IOR is converted back into a servant object reference via the CORBA-defined operation named string_to_object. Thereafter, a client reads the IOR file and converts the IOR into a servant object reference, which is used to create the proxy for the client. Since file input/output is relatively slow, this method rarely satisfies the startup requirements for a real-time system.
Another common CORBA discovery technique employs the Naming Service as specified by OMG (the OMG Naming Service has two versions: the original Naming Service and the Interoperable Naming Service). The Naming Service plays the role of a bootstrap service that facilitates the initial connections between clients and servers. The Naming Service binds a given name to a specific object reference. For purposes of discovery, a server registers its servant object reference with the Naming Service under a pre-defined name. The client then queries the Naming Service with that name and receives the servant object reference in return. The client then creates the proxy using the servant object reference. This methodology demands that the Naming Service be available, the server be alive, and the servant registered before discovery can be successful. In practice, however, it is difficult (especially in distributed architectures with inter-dependencies) to assure that the server will be alive and its servant registered prior to a client query for the designated name. In such cases, client applications might need to actively poll the Naming Service, until such time as the servant is registered.
A real-time alternative to polling is to asynchronously notify clients that the servant is available, i.e., employ the Event Service, which is defined in a separate OMG specification. In place of the Event Service, the OMG Notification Service, which is often described as an extension of the Event Service, may be used. CORBA applications must perform discovery on the Event/Notification Service to gain access to event channels. The Event Service enables the server to push a notification (e.g., servant object reference, servant IOR, etc.) through an event channel. A client that is passively listening on the event channel receives the notification, which is used to create the proxy. Using the Event Service in this manner is actually an extension of the second method described above, since the client needs to query the Naming Service first. In this regard it is important that the client first gain access to the event channel before querying the Naming Service to avoid the possibility missing the notification from the server. Should the client receive the object reference via the Naming Service, a coincidental event-channel notification can be ignored. In addition, most event channels do not guarantee durability of a notification and, therefore, clients need to query the Naming Service. Once the client has the servant object reference, the connections to the Naming Service and Event Service can be terminated. However, the Naming Service and/or Event Service must remain active.
For the reasons discussed above, conventional CORBA discovery techniques have shortcomings that can make them difficult or cumbersome to develop, implement, and test. Accordingly, it is desirable to have an improved CORBA discovery methodology that leverages non-CORBA data communication techniques. Furthermore, other desirable features and characteristics of the present invention will become apparent from the subsequent detailed description and the appended claims, taken in conjunction with the accompanying drawings and the foregoing technical field and background.